home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20000824-20010305 / 000074_news@columbia.edu _Mon Oct 16 17:09:36 2000.msg < prev    next >
Internet Message Format  |  2020-01-01  |  6KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
  3.     by fozimane.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA18055
  4.     for <kermit.misc@cpunix.cc.columbia.edu>; Mon, 16 Oct 2000 17:09:36 -0400 (EDT)
  5. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  6.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id RAA15733
  7.     for <kermit.misc@watsun.cc.columbia.edu>; Mon, 16 Oct 2000 17:09:35 -0400 (EDT)
  8. Received: (from news@localhost)
  9.     by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id QAA01178
  10.     for kermit.misc@watsun.cc.columbia.edu; Mon, 16 Oct 2000 16:40:25 -0400 (EDT)
  11. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  12. From: fdc@columbia.edu (Frank da Cruz)
  13. Subject: Re: No Carrier
  14. Date: 16 Oct 2000 20:40:24 GMT
  15. Organization: Columbia University
  16. Message-ID: <8sfp3o$14n$1@newsmaster.cc.columbia.edu>
  17. To: kermit.misc@columbia.edu
  18.  
  19. In article <%ZHG5.54658$bI6.1914001@news1.giganews.com>,
  20. Steve <steve@baus-systems.com> wrote:
  21. : We currently have DOS clients that on a regular basis, communicate with a
  22. : host PC to exchange files.  The clients and the host are running DOS apps
  23. : that call Kermit 3.15.  We would like to upgrade the host to K95 to allow
  24. : for multiple transfers at one time on one PC.
  25. : 
  26. : Here is what we are doing:
  27. : The host waits in server mode for a client to connect.  The clients connects
  28. : either through a serial cable or modem...
  29. :
  30. So then you need one serial port for each simultaneous session.  As you know,
  31. PCs are not easily able to accommodate more than two serial ports, due to
  32. the severe shortage of available IRQs in the PC architecture.  Any serial 
  33. ports beyond two are likely to introduce interrupt conflicts.
  34.  
  35. : ... and sends across a file that contains
  36. : a field that tells the host which client this is then the client sends a
  37. : Finish command to kick the host out of server mode.  The host opens the file
  38. : to get the client ID then changes to a directory containing files specific
  39. : to that client that are waiting to go to the client, compresses the files
  40. : and sends across the compressed file.  The host then goes into server mode
  41. : waiting for the clients compressed data file.  After the client sends the
  42. : file it sends a Finish command and the host uncompresses the file and
  43. : processes the data, copying files contained within the compressed data file
  44. : to the appropriate places.  The host then goes back into server mode waiting
  45. : for the next client.
  46. :
  47. All this switching into and out of server mode sounds pretty tricky to me.
  48. How do the two sides stay synchronized?  Wouldn't it be better to keep the
  49. host in server mode and drive everything from the client script?
  50.  
  51. For example, make the client ID correspond to a directory on the host.
  52. Then the client script could:
  53.  
  54.  . CD to its own host directory.
  55.  
  56.  . Does a GET command for the files that are waiting.  Note that both
  57.    K95 and MS-DOS Kermit 3.15 have a RETRIEVE command, which means
  58.    "send me the specified files, and then delete each one if and only
  59.    if it is sent successfully" (in K95, this is equivalent to GET /DELETE).
  60.    This feature is designed for exactly your kind of application.  For
  61.    more discussion of "atomic file movement", see:
  62.  
  63.      http://www.columbia.edu/kermit/case10.html
  64.  
  65.  . I would guess that the compression step can probably be skipped, since
  66.    the modems take care of that transparently.  In those cases where you
  67.    might not have a data-compressing modem connection, the improved
  68.    simplicity might be worth the tradeoff.  Conversely, you have have the
  69.    client script obtain send "remote host zip" or similar commands.
  70.  
  71.  . Now the client sends back its files and sends FINISH, and hangs up its
  72.    connection.
  73.  
  74. This makes the server end quite simple.
  75.  
  76. : One other important part is from time to time a phone
  77. : line can go bad in the middle of a transfer and therefore for example the
  78. : host may be waiting for the clients compress data file while a new client
  79. : may be connecting and sending the client ID file.
  80. :
  81. This, of course, points up the dangers of using a DOS/Windows server, which
  82. has no notion of separate user identities or authentication.  You would solve
  83. an awful lot of programs by using some form of Unix (such as Linux or SCO)
  84. on the server.  This gets you user IDs, file protection and permissions, and
  85. all the rest automatically, not to mention the natural ability of the Kermit
  86. server to run subprocesses without hanging.
  87.  
  88. : We refer to this as the
  89. : client and the host being out of synch.  To resolve this, when the client
  90. : first connects, it sends 2 Finish commands which 100% guarantees that the
  91. : host will be at the "waiting for client ID" section of the host app as that
  92. : part of code on the host looks something like:
  93. : Do While True
  94. :  Kermit server
  95. :  If File(ClientID)
  96. :   Exit Do
  97. :  End If
  98. : End Do
  99. : 
  100. : We would like to upgrade the host app to K95 and have a VB app that seems to
  101. : work fine except for communicating over the modem.  When we send the Finish
  102. : from the client, it drops the line and we get No Carrier on the client.  If
  103. : we could get around this, that should solve our issue.  I am not sure
  104. : changing the software on the client is a realistic option as updating the
  105. : clients is a major hassle.
  106. :
  107. Still, it might be worth it.  The current scheme has too many vulnerabilities,
  108. both procedural and security-related.
  109.  
  110. : We can change the modem initialization string on the clients so that is an
  111. : option.
  112. : 
  113. : Any thoughts?
  114. :
  115. It's up to you.  If you can't change the client scripts, then you'll need
  116. to make the server script take every possibility into account.  If you want
  117. to continue with your current scenario, Jeff already made the suggestions
  118. you need -- remove the EXIT command from your script, and have the script
  119. loop back and wait for another call.  Or put two SERVER commands in a row.
  120. Whatever you need to do, the scripting language will allow -- you just need
  121. to think through all the possibilities.
  122.  
  123. Another possibility is to simply run K95 host mode on server:
  124.  
  125.   http://www.columbia.edu/kermit/k95host.html
  126.  
  127. In that case, the client script has to log in and negotiate the menus, but
  128. that's not too difficult, and then at least you have some measure of
  129. authentication and file protection.
  130.  
  131. - Frank